An Overview of ARIA Live Regions
On this page
We’ve talked about focus management and we’ve explored how screen readers navigate. Now we’ll dive into another important aspect of accessible web applications: screen reader announcements.
Announcements are used when we want the screen reader to alert a blind or low vision person that something has happened on the screen without moving their focus. In the examples we’ve seen so far, announcements have mostly occurred as a result of page loading or through user interactions and focus management.
Autosave is an example where a different type of announcement would be beneficial. Picture an interactive form for typing with a toast notification that pops up to say that work has been saved.
We want the screen reader to announce that this action occurred for the user’s peace of mind but not disrupt their writing flow by moving focus from the text box.
We can set the announcement to happen after a pause in typing but keep the user’s focus point in the same place for ergonomics and usability.
We’ll accomplish this by using ARIA live regions.
Video Transcript
You know, we've talked a lot about focus management. We've seen how screen readers navigate. There's another piece to this puzzle of interactions that I want to tell you about, which are announcements in screen readers.
So sometimes we might want to alert a screen reader, user to change is happening on screen without moving focus, there's use cases for that. It could be things like. Autosave is a big one. So if I'm typing in a text area and we've got an asynchronous process happening where it will go and save my changes to a server, maybe there's a little toast notification or something that shows on screen that says saved, you know, to kind of give you that kind of peace of mind as a user that it's going to save my changes.
I don't need to be like, oh my God, if I close this tab, am I going to lose my work? You know, kind of getting that reassurance that the application is going to save what you've been working on in a screen reader. We might want to notify about that asynchronous action, but not interrupt the flow. You know, the flow state that someone is in when they're typing.
So if we have periodically and announcement, you know, maybe it's you kind of wait until they're done typing. And in the pause, it might say, you know, save changes or something. We want to make an announcement without moving the key, the user's keyboard focus. That's where these announcements come in and we do those with a tool called aria live regions.
ARIA Live Region Roles
Follow along in the ARIA Specification Documentation.
When you add an ARIA live region role to an element in your markup, the screen reader will automatically make announcements.
Elements with live region roles must be present when the page loads for announcements to get picked up.
For example, if you have a toast notification component that pops up it needs to be appended to a persistent element that already has a live region added to it. Otherwise, the screen reader might not announce the change because it didn’t know to poll for messages.
There are several live region roles defined in the ARIA spec, each used in different situations. They work best on block-level elements such as divs, as opposed to inline elements like spans.
alert
The alert role is used to tell the screen reader you have really important, time sensitive information to announce.
It will interrupt any other announcements that may be happening.
The alert role is not intended for moving the screen reader user’s focus point. If mimicking JavaScript window.alert with ARIA is your desired behavior, there is an alertdialog role defined in the spec that follows this behavior.
status
The status role is used in situations where you want an asynchronous message center. Like alert, role="status" is typically added to a div that may be visually hidden.
The screen reader will not interrupt announcements for a status update.
log
The log role is similar to status but is meant more for things like chat logs, game event logs, or error logs.
There is a relationship between when something shows up and the reading order when using log , compared to the status role where messages may be replaced.
marquee
If you remember the old HTML marquee element, then you have a pretty good guess for what this live region will do.
While using the marquee role doesn’t visually change the page, it is meant for non-essential information that changes frequently. Think stock tickers, for example.
I’m not sure that you’d necessarily want to use the marquee role.
The Danger of Using Roles Incorrectly
There is such a thing as too much information.
One of my favorite anecdotes about live regions gone wrong involves a version of the Facebook chat widget.
The user could have multiple conversations going. At random intervals, the screen reader would announce “Five minutes ago. Ten minutes ago. Two minutes ago.” and so on for every conversation. It was definitely overkill.
Similar to the note about the marquee role above, you might not realize how annoying that many announcements might be unless you use a screen reader all of the time.
I mostly use alert and status in my work, testing frequently to ensure messages read as expected.
Video Transcript
So if we go over to the aria specification live regions are part of the ARIA specification. So there's kind of two main ways to add them. One is with roles. So if we do role status is one of them. Let's come down here to our live region roles. So there is alert, log marquee status and timer.
So those are all live region roles. And what that means is that if you have one of those roles on an element in your markup, it will automatically make announcements. And there's some slight differences with these roles. For example, with alert, this is for a really important and time sensitive information.
Like if you're going to be logged out If there's something that needs immediate attention and it should interrupt other screen reader messages or screen reader announcements role alert might be the correct one. It does say, see related alert, dialogue alert, dialogue is slightly different. It's like a combination of an alert and a dialogue, as you might imagine.
But a dialogue is something that you're actually moving focus into. It's like a custom version of the JavaScript window dot alert, which will open kind of a, you know, a blocking interrupt modal thing that you have to hit. Okay. To get out of alert. Dialogue is a custom pattern for that. So a role of alert.
Doesn't include moving of focus. So that's kind of the big difference is that a dialogue you would be moving focus to it. And so it has all of those dialogue requirements as well. Whereas roll alert is something that you might use as just a message center. That's still this asynchronous, we're not moving focus.
And we'll play with this in the browser. So you'll see what I'm talking about. But role alert is for time sensitive announcements that don't move focus.
There is also role of status. And so this one is also a sort of asynchronous message center type thing, where we put a role of status on an element like a div, it might have visually hidden on it.
And so when we update the text content in an element marked with role of status, it will automatically pipe those announcements to the screen reader.
So with these live region roles, they need to be present when the page loads. So a bit of kind of housekeeping notes about how to use the status roles or live region roles, or really any live region features is that they have to be there when the page loads kind of polling for changes.
So if you have a toast or a component that's getting added to the page, it needs to be appended into something with a live region on it. When you append it to the page, that might be too late for the screen reader to pick it up. So if the toast itself had a live region, a bit of live region functionality, the screen reader might not announce it.
Cause it's it hasn't been sitting there waiting for changes. So role of status of status, won't interrupt, screen reader messages. It will wait and kind of add this announcement to the queue. So there's also role of log which is. Really similar to status. It's mentions that it's for chat logs, messaging history, a game log, or even an error log.
In contrast to other live regions in this role, there is a relationship between the arrival of new items in log and the reading order. So if you had a chat window or something that does kind of indicate that there's some sort of an order, whereas role status might just be kind of one-off messages that replace what was there before.
So kind of a slight semantic difference, but in terms of functionality, the announcements of role log and role status are pretty similar. And so these log messages are in a meaningful order and old information may disappear and it points us over to marquee let's go check out marquee because that's one of those old HTML elements that would actually like combine content and presentation and it would scroll stuff across the screen.
So in ARIA role, when we're adding it to something will not have any effect on the visual of the page, but we apparently have this role for non-essential information that changes frequently. So stock tickers, and had banners. I can only imagine how annoying a marquee live region would be, because it would just be like, I mean, imagine a webpage.
That's just like updating you all the time. And you're like, oh my gosh, stop reading aloud. So just because you can use marquee. I don't know that you'd necessarily want to yeah, there is such a thing as too much information and sort of related to live regions in general. Kind of one of my favorite anecdotes is about the Facebook chat widget.
How you can have multiple conversations going. There was a version of it at one time where every chat window was announcing its date and it would update. It'd be like five minutes ago, 10 minutes ago, 30 minutes ago, like all of these chat windows, all these instances were all making automatic announcements about time passing and.
You might not know how annoying that is, unless you have a screen reader running all the time. So use these thoughtfully and carefully. We don't just want to go slap ARIA stuff onto our pages without testing it, because it is this kind of under the hood API, that if you aren't ever turning on a screen reader, you might have no idea what the effect is.
And it could be really annoying, especially marquee like, oh yeah. Cringe. I haven't found a good use for marquee yet. Mostly using alert and status. So these are the roles.
ARIA Live Region Properties
In addition to the roles, there are also several live region properties.
aria-live
The aria-live property is useful in situations where you might want to make a live region out of something that already has a role that you don’t want to override.
For example, say you have an unordered list you want to be read aloud when its list items are changed while preserving its semantic markup. Or, you could mark a landmark element to be announced when re-rendered as a low-fi approach to client-side routing.
aria-live takes values of polite or assertive to mimic the whether-to-interrupt behavior of role="status" and role="alert", respectively.
aria-atomic
Setting the aria-atomic property to true will read the entire element. Otherwise, it will default to announcing only the part that changes.
aria-relevant
With aria-relevant, you can make the screen reader announce additions, removals, text, or everything that changes.
aria-relevant has limited support in Assistive Technology, so be sure to test it. You might need to adjust your messaging approach if you run into limitations.
Choosing the Right Approach
Going with roles or properties to set ARIA live regions can depend on the use case. Components can also benefit from a higher-level API to manage and orchestrate messages, as opposed to letting each and every component inject its own live region. Creating a API that you can centralize messages through can help abstract some of these details away.
In the next lesson we’ll follow this approach with the react-aria library as we start applying live regions to the process of form validation.
Video Transcript
There are also Properties. So some of them that relate to this I can see, so aria, atomic is one that will change whether it reads all or only parts of the changed region.
So there's also ARIA relevant and sometimes these work or don't you sort of have to play around with them a little bit, but ARIA relevant we are going to use in our example, and this, you can have it read additions, removals, text, or a single catch, all value of all. So if you're appending new text and you want it to read everything you can set ARIA relevant to say what's relevant to be reading aloud.
Or you could only, you could have it read with only what's new. So that could become relevant in role of log, kind of depending on how that works by default, you can fiddle with the settings with things like ARIA relevant.
There's one other piece. I want to show you. So we've seen the roles, we've seen some of these properties.
There is also a aria live property. So sometimes you might want to make a live region out of something that already has a role. And we want to leave the role the way it is. Maybe it's a, maybe it's a section and it also works as a region. And we don't want to change it semantics, but we want to make it read aloud.
When, when content is appended to it, you might have some legitimate use case for that. So we kind of need both methods of applying a live region. So a role of alert or a role of status or log, you know, if you're just putting it onto a div that its only purpose is to be a message center. Then maybe the role is appropriate.
You might also have cases where that already has a role. Maybe it's an unordered list or something. And so you need to add this functionality while preserving its semantic role. We have this thing called aria live and it has different levels of polite or assertive. And so it changes the kind of priority of the messages that are read aloud.
You could use this with the live region roles as well. So if you wanted to, for some reason, change the way that those roles work and you could, I mean, role alert is assertive by default. It will interrupt whether you have ARIA live assertive, or a role of alert. And that means that if their screen reader messages.
It's announcing a summary of the page, or, you know, we're listening to the markup of a button and everything that it's nested inside of. If there's a, an alert message that pops up, it would interrupt what was being read already. And so we can control that with ARIA live, as well as some of these specific roles, so ARIA live of polite or Ari live of assertive.
There's also the default of ARIA live of off, and that would turn something off. Haven't really ever had a use case for that, but it's an option. So this is where live regions are defined is in the ARIA specification. And so we've talked about a few use cases like asynchronous, save chat, widgets stock tickers, although be careful with those because it could be, you might want to wait to like, get it to shut up user perspective.
Like maybe you could have announced like, Screen reader or stock ticker announcements paused to reenable press this keyboard shortcut or, you know, something like that to give the user control over, turning it off and on again, because it could get, I mean, talk about distractability visually, if your screen reader is just like going off and there's no way to stop it, people are probably going to leave your site application.
So make ways to turn these things off. If possible, if they're going to just continually go, it's like another version of autoplay almost.
So we need things they used to be present on page load. There might be context reasons for why we might choose a certain level or a certain role.
So choosing the right level role versus property kind of depends on what it's getting put onto. We could also talk about the context per component. So it might be helpful to have an API. Like if you have a broader web application, maybe you have an API that you kind of centralized messages through.
In our example, we're going to use a library from the react aria project. And that is another way of kind of centralizing our functionality for our live regions, kind of have a live region announcer. And so components could tap into that and really so that you don't get these live regions just littered across your entire application.
It could be. Yeah. Like if you have a queue of announcements, you don't want them to be competing with each other. If you have all these like asynchronous things going on, like if there, if you have multiple assertive messages going on at once that you might not hear them all, you might only hear the whichever one was the most recent, because it really will interrupt other things, including other announcements that you may have wanted to announce.
So be careful with the assertive and alert stuff. So the way that we are going to work with this is we're going to apply it to some form validation and. That will be done in our application. So a quick note about how to test screenreader announcements, you can really only test these manually because they are screenreader functionality and we can't automate Not quite yet someday. Hopefully we'll talk about more about automation but for live region announcements, you really have to have a screen reader running and you just have to test it manually. So let's add a live region and we'll see what effect it has in voiceover and NVDA.